Why Accessibility Isn’t Optional: How We Build a Kinder Web

by Mylene — 5 minutes

For developers who want to build better, human-first websites and finally understand what real accessibility looks like.

You never forget the first time you hear the web. Not see it. Hear it.

That moment during the accessibility workshop when someone who was blind used a screenreader to navigate a website, and you realised: everything we build gets read out loud, every repetition, every empty label, every meaningless image, image, image...

The internet, through their ears, felt like a chaotic avalanche of noise. Until, suddenly, they landed on a well-built page and the sigh of relief was almost palpable. Structure. Flow. Sense. A little peace in a jungle of bad markup.

Accessibility isn't a bonus. It's a baseline. And it's time we act like it.

What accessibility really means (and for whom)

Accessibility isn’t just for blind users. It's for anyone who struggles to access or interpret the content we build.

Think of someone with dyslexia, who finds long paragraphs overwhelming. Or a user navigating with a keyboard because their hands tremble too much to use a mouse. Or an older visitor with fading vision and cognitive processing speed. Or someone with ADHD, overwhelmed by flashy animations and endless dropdowns.

Accessibility means:

  • people with dyslexia, ADHD, or cognitive overload
  • people with low vision or colour blindness
  • older users with declining motor skills
  • anyone navigating via keyboard, voice, or braille
  • users with sensory sensitivities or mental health challenges

In short: it's for people. Like your users. And even ours.

During the workshop, I found myself wondering: can blind users also have dyslexia? It felt like an odd question at first but after looking into it, the answer was yes. Unexpected, but true. Human brains are complex and the web we build should meet them where they are.

Real-life frustration: how the web can overwhelm

Here’s a scene from the workshop: we’re watching a screenreader user try to navigate a site. They hit tab, again, and again... and again. Each press brings a new link with the same label: “Read more.” The same heading repeats five times. Then: “image.” Another “image.” No description. No clue. No orientation.

It’s like walking into a building with no signs, no lights, and a looping elevator voice that just says “floor.”

For someone using a screenreader, that’s not just frustrating, it’s exhausting.

We heard and saw:

  • Repeated phrases and headings without purpose
  • Alt-text that simply says "image"
  • Buttons that say "click here" with no context
  • No way to skip repetitive menus

Imagine reading a book where every page starts with the same title, but you can't turn it unless you guess what the next heading means. That’s what poor accessibility feels like.

What we can do, starting today

You don’t need to rewrite the entire front-end universe. You just need to start thinking about what you’re really building:

A page? Or a pathway?

Here’s how to build one worth walking:

  • Use semantic HTML: nav, main, section, h1-h6, ul, button, label—they’re not optional. Native HTML > ARIA. Use ARIA only when necessary, and always test it.
  • Add meaningful alt-text: If you were explaining this image to someone over the phone, what would you say?
  • Ensure keyboard navigation: Try tabbing through your own site. Can you get everywhere you need to go?
  • Include a “Skip to main content” link at the top of your page
  • Use focus outlines: They’re not ugly. They’re lifelines.
  • Validate forms accessibly: use clear error messages, visible and screenreader-friendly
  • Test your site with a screenreader or simulator: You’ll learn more in five minutes than from five articles.
  • Structure pages with clear headings and hierarchy: Not for SEO. For orientation.

Tip: If a user turns off their screen and still understands your content, you're on the right track.

What the guidelines (and law) say

Let’s talk law—but keep it human.

The WCAG 2.1 is the gold standard. It tells us how to build inclusively. The European Accessibility Act brings the force of legislation.

According to the W3C, accessibility is not just a technical standard—it’s a moral imperative for inclusive design. And a 2023 audit by the EU Commission found that over 70% of public-facing sites still fail on basic accessibility checks.

Here’s what that means for us:

  • Existing websites must gradually be made accessible
  • New websites must meet accessibility criteria before going live
  • Public sector and commercial services are both affected

If you build digital services in Europe, this isn’t optional. It’s essential.

What about contrast?

Contrast gets a lot of attention—and for good reason. But the tools we use to check it? They’re not always right.

We saw this in practice: text passed the checker, but on screen, it still felt unreadable. Sometimes subtle backgrounds trick the algorithm. A few pixels one way or another, and it fails.

Use tools like WebAIM's Contrast Checker as a guide. But when in doubt, ask a real person.

Final thoughts

What struck me most in the workshop was this: when the screenreader finally landed on a clean, accessible site, the voice changed. The tension dropped. It was easier. That is the power of accessibility.

We build for people we may never meet. Some of them hear what we write. Some feel it through braille. Some depend on it.

Let’s not make them fight for it.

Want to learn more?

Accessibility isn't an extra. It's how we make the web humane.

meerdivotion

Cases

Blogs

Event